To address the retention problem Wefight was facing (more context here), we had to find an overlap between users' need to motivate them to stay on the app after they understood their disease, and business' goals to collect more recurring data.
Better manage their health was the logical next step of our patients' journey. We already had reminders in place for treatments, appointments and other events, but too few patients were using it because the flow to create those events was centered around their needs. For instance, there was no options of periodicity offered to patients when adding a treatment to get reminders, which would then set by default a reminder every day to patients at the single hour they entered in the flow. How would you do if you only had a treatment to take twice a week for 2 weeks? No wonder why 1/3 of patients ended deleting their events this last month, and were then reluctant to use this flow.
What a pity though, because on one hand events like those were recurring data which would have helped Business tremendously, and on the other hand it was one of patients' wishes on that segment to keep track of the events related to the disease, as per the retention survey Marketing issued before my arrival. In a nutshell, it was a great alignment poorly exploited, thus why I decided to optimize the current event creation flow.
To get there, I had to rethink the user flow and its functionalities to center the experience around the patients' needs. Over a couple of sessions with Product and Architecture teams, we discussed the base of user flow I set to align users' needs with internal constraints. The cover picture of this project page witnesses the evolution of this base. In an ideal case scenario, patients wouldn't have to enter anything and we would have gotten their recurring data through 3rd parties integrations. All events creation would have been automated. But we weren't there Tech wise, so it was a matter of negotiations to get the least number of manual inputs possible while adding crucial functionalities for the users, such as complex treatment regimen, allowing them to get treatment reminders that were really fitting their prescription. Those negotiations went up to agreeing on the Archi object for each Event Type, as the one below.
Once the flow was all set up, it was time to give it visibility. As you can see in the initial flow, you could only add a new event by clicking "Agenda". Since those data were important for Business, I decided to bring them forward in the tab bar. It was a good opportunity to redesign the tab bar, to modernize it but mainly to fix the accessibility issues it had: the label font sizes were too small, the icons too complicated and the colors not contrasting enough.
The collaboration Design / Tech so far consisting in a lot of custom development, which I didn't consider sustainable since we had more and more products to maintain with a decreasing amount of resources. Switching to Material Design 3 for basic patterns (e.g. tab bar, fields) was according to me a cost efficient way to increase the quality standard while decreasing the development time.
Below are all the flows corresponding to each event creation. Pushing for an upload at the beginning of each flow enabled to limitate the number of manual entries since the 3rd party used for the upload enabled text recognition, which was the compromise that was done during the negociations between Tech and Design.
